1. Field of the Invention
The disclosed methods and systems relate generally to management of software updates, and more particularly to methods and systems for managing software updates through a group/policy management system.
2. Background Information
Software is in an almost constant state of flux. Programmers modify software for a number of reasons, including changing features to meet the new needs of their users, adapting programs to work with new and/or modified hardware and/or other software, and repairing errors as they are discovered, among many others. Requiring their users to purchase new versions of existing software every time a vendor changes a software product, however minor the change may be, is not efficient or practical. Instead, vendors release software updates, sometimes called patches, to the users of their software. A software update contains code that effects a change or changes in the software. Software updates are particularly necessary to repair security holes in software products, such as operating systems, that make users' computers potentially vulnerable to attack by hackers, viruses, worms and the like. In such a scenario, the necessary updates may vary from computer to computer on a LAN, depending on the type of operating system running on each computer and how frequently it has been updated in the past. Thus, a system for managing software updates across a network of varied computers would be useful.
In WINDOWS®, a Group Policy Object (GPO) is a collection or grouping of configuration settings that are applied to computer users and/or computers/systems automatically and/or remotely. Group Policy is a MICROSOFT® implementation of the general concept of policy-based management, which is a computer management model similar to Object Oriented Programming in the realm of software development. One potential implementation of a group policy system is described in U.S. Pat. No. 6,466,932. By applying the configuration settings to the computers/systems, a system administrator or other can define and/or determine the behavior and/or “appearance”/configuration of the computers/users. Accordingly, a GPO is generally configured by a system administrator or other high-level administrator, and as an object, a GPO can be associated with a hierarchical grouping known as a “container.” A container may be a domain, a site, an organization unit (OU), or other association of computers/systems/users. In some example instances, a GPO may define script options, security options, software-installation options, folder-redirection options, software-maintenance options, and other configuration options.
Each GPO has an Access Control List (ACL) that controls whether the GPO's settings are applied to given users, groups, and/or computers. An entity that is on the ACL has the GPO's settings applied to it. An entity not on the ACL does not, at least in response to that GPO. In this manner, GPOs may be applied based on a user/computer's group membership, and this capability may be referred to as GPO-level filtering. Accordingly, GPO-level filtering allows a system administrator or another to specify whether a GPO is applied or denied to users/computers. The GPO is thus applied in its entirety, or denied in its entirety, to a user/computer/system.
In a MICROSOFT® WINDOWS® implementation, GPOs are populated with settings by extensions or plug-ins to a Group Policy Object Editor (GPOE). Settings are actually applied on client computers by corresponding extensions, called Client-Side Extensions (CSEs). The reporting system (Resultant Set of Policy, or RSoP) is part of the model, and uses another extensible component, called the RSoP snap-in. There is a documented extension model that MICROSOFT® provides for software vendors to extend all three systems and, by doing so, provide new functionality within the WINDOWS® Group Policy architecture.